Hosting a web resource on a hidden network implies that you do not want the physical location of the server to be discovered. When professionals set out to reveal the identity of the owner of a particular site, everything is used: from social engineering to analyzing the metadata of images posted on the site and the like. In this article, we are interested in a timing attack based on the comparison of various events in time and their logical connection. For example, suspect N entered the house, after which five minutes later his supposed virtual identity appeared in the chat. In more realistic cases, the time the suspect appeared online may hint at his time zone. There are countless such observation techniques.
Experience with burned down OVH data center showed that even users of top data centers are not protected from timing attacks. The abrupt departure of several services offline at the time of the fire perfectly demonstrates the narrowing of the circle of suspects - you need to look among the clients of the affected data center.
In I2P there is a technique called multihoming. The term “multi-homing” comes from the English words “multi” and “home” - it can be translated into Russian as “simultaneous placement of a web resource on several hosts.” Below we will consider the essence of this phenomenon.
The material presented may be useful to a wide range of administrators, students and the curious, and in no way is intended to encourage the reader to commit illegal actions!
Look for fistulas
I2P routing is described in article about floodphiles. Briefly, the essence comes down to this: the intranet address is tied to cryptographic keys that are locally stored on the server.
A simple implementation of multihoming does not require shamanic skills, since it is a banal deployment of two identical web servers, which, with the same keys, have the same I2P address. In this case, it is impossible to actually predict which of the two servers the user will end up on. Yes, he, in fact, won’t even know..
In order for the scheme to make sense, all servers must be located in different places (different data centers, jurisdictions and even continents). By the way, there may not be two servers, but at least a hundred. If a targeted attack occurs, or an accidental emergency occurs with one of the servers, nothing bad will happen - users will receive a LeaseSet from a server that is still online and no one will be able to conclude that the disconnected server or data center hosted your hidden web resource. In the case of static sites, this is a ready-made implementation, and for resources with a backend (database, etc.) - all web servers displayed in I2P must link to the main server, that is, act as a proxy.
Here the weak point that they tried so hard to get rid of becomes obvious - the main server. In some configurations, it is possible to imagine complete mirroring between two autonomous servers, but in complex and highly loaded projects that use cookies and various databases, everything depends on at least one server, existing in a single copy, the loss of which will inevitably affect the performance of the web resource (if I’m wrong - please describe the configuration in detail in the comments). Obviously, the critical server must be located in the most secure location.
I2P is not famous for the speed of information transfer, so in most cases it is advisable to organize the connection between proxy servers and the main one through a fast secure connection like VPN or Yggdrasil. If you approach it wisely, you should try to plan the architecture in the style of the elusive Joe, so that a compromised dummy server cannot serve as a hint about the placement of the main server... Let's leave this puzzle to the reader.
Practical implementation
This time there won’t be a lot of letters about a complex configuration, because everything is extremely simple. On all clone servers a normal server tunnel using the same keys. It should be noted that it is not the names specified in the config that should be the same, but the files. To do this, you need to copy the key to each server, placing it in the i2pd working directory. Typically this is /var/lib/i2pd/, but the exact path can always be found in web console ("Data path" parameter). The intricacies of website proxying are beyond the scope of this article, but the topic is easy googles and in trivial cases it results in several lines of the web server configuration file.
If you are interested in secure hosting of resources in I2P, it makes sense to place on rented servers not the main key, which is entirely responsible for the intranet address, but a temporary one, the theft of which will not result in a fatal loss. Read more about this in a separate material.
